1. Field of the Invention
The present invention relates generally to authentication and authorization policies for network access services, and more particularly to a segmentation of such policies into sub-policies to support multiple types of access services for a network simultaneously with different policies for each type of service being defined.
2. Description of the Related Art
Authentication of a user prior to access into a network being granted generally protects the network from unauthorized access. Authorized users of a network may exemplarily be subscribers of an internet service provider that provides web access services over the Internet or employees of an enterprise that provides corporate enterprise services over a local area network. In either event, before the user may gain access to the network, the user typically provides a user name and a password from the user interface of the device used to access the network, and if the user name and password are recognized and deemed valid, the user is then authorized to access the network through such device.
Many different network access policies and authentication protocols are well-known and, accordingly, need not be set forth herein in detail. However, several different commonly encountered authentication protocols are generally described below so that a greater appreciation of the advantages and features of the present invention may be obtained.
One well-known authentication protocol is the Remote Authentication Dial-In User Service (RADIUS) protocol. The RADIUS protocol is a client/server protocol and was originally developed as a network access server authentication and accounting protocol. The RADIUS client is typically a network access server and the RADIUS server is usually a daemon process or service running on another computer in network communication with the network access server.
Upon the user initiating a connection from the user device to the network access server, the network access server prompts the user for a user name and password, and the user replies causing the username and password to be sent to the network access server. The network access server, acting as the RADIUS client, sends an Access-Request packet containing the user name and encrypted password to the RADIUS server. In response to receipt of the Access-Request from the RADIUS client, the RADIUS server searches a database for the username listed. If the username is found and the password is correct, the RADIUS server then returns an Access-Accept response to the RADIUS client. Upon receipt of the Access-Accept response the user becomes authenticated on the network access server and thus obtains access to the network that the network access server protects. If the username does not exist in the database, the RADIUS server returns an Access-Reject message, which may further be accompanied by a text message to be forwarded by the RADIUS client to the user indicating the reason for the refusal.
In the example above the connection between the user device and the network access server is governed by the Point-to-Point Protocol (PPP). PPP has evolved beyond its original use as a dial-up access method and is now also used by some ISPs for DSL and cable modem authentication, in the form of PPP over Ethernet (PPPoE). PPP is part of the Layer 2 Tunneling Protocol, and also includes an authentication protocol that provides a prompt for a user name and password as described above.
The user name and password combination is the most common method for providing basic security from unauthorized access to networks. There are also more robust protocols for controlling network access and authenticating users that are well known. One such protocol is the Extensible Authentication Protocol (EAP). EAP sits inside of the PPP authentication protocol and provides a standardized framework for several different authentication methods so that the network access server does not need to be cognizant end of the authentication protocol being used. A network access server that supports EAP does not act as middle man in the authentication process described above, but just packages and repackages EAP packets received from the user device to hand off to a RADIUS server that will do the actual authentication.
In addition to user authentication as described above, wherein the user may access the network from any port provided by a network access server, network access may also be controlled by enabling and disabling the physical or logical port to which the user device is attached. Port access control is particular useful for controlling access to wireless local area networks wherein an unauthorized user device may establish an active link with a port of a wireless router.
One port based access control system is the IEEE 802.1x standard, which is a standard for passing EAP over a wired or wireless local area network (LAN). In an 802.1x compliant system, EAP messages are encapsulated in Ethernet frames instead of sitting inside of PPP packets. Accordingly, 802.1x provides for authentication and no other service, which may be desirable when using protocols other than TCP/IP, or where the overhead and complexity of using PPP is undesirable.
In the terminology of the 802.1x standard, the user device that wants to be authenticated is called a supplicant. The server doing the authentication, typically a RADIUS server, is called the authentication server. The device in between a supplicant and the authentication server, such as a wireless access point or port of a network access server, is called the authenticator. An advantage of the 802.1x standard is that the authenticator simply passes frames encapsulating the EAP packets between the supplicant and the authentication server. The protocol in 802.1x is called EAP encapsulation over LAN (EAPOL), and is currently defined for Ethernet-like LANs including 802.11 wireless, as well as token ring LANs.
Generally, the authenticator sends an “EAP-Request/Identity” packet to the supplicant as soon as it detects that the link is active (e.g., the supplicant system has associated with the access point). This packet is then passed on to the authentication (RADIUS) server. The authentication server sends back a challenge to the authenticator, such as with a token password system. The authenticator unpacks this from IP and repackages it into EAPOL and sends it to the supplicant. Different authentication methods will vary this message and the total number of messages, EAP supports client only authentication and strong mutual authentication, the latter being particularly useful for wireless LANs. The supplicant responds to the challenge via the authenticator and passes the response onto the authentication server. If the supplicant provides proper identity, the authentication server responds with a success message, which is then passed onto the supplicant. The authenticator now allows access to the LAN. However, the access may possibly be restricted based on attributes that came back from the authentication server. For example, the authenticator might switch the supplicant to a particular virtual LAN or install a set of firewall rules.
In an enterprise environment, a user may be granted access to the enterprise network in various ways. The user may have any or all of a desktop computer hardwired to a network switch, a wireless laptop, a personal digital assistant (PDA) and an internet enable cellular telephone, all of which may be used to access the network using one of the various known authentication protocols. Such user may also have another desktop computer on a home network that may access the enterprise network through a virtual private network (VPN). Should this home network also be wireless, the wireless laptop may also use the VPN. The wireless laptop, the PDA or the cell phone may further be used to access the enterprise network from wherever a connection to the Internet may be established, such as from publicly available “hot spots” in airports and Internet cafes.
Although any known authentication protocol may be used as appropriate for the connection to be made to the enterprise network, the enterprise administrator does not have available any known unified system or method to implement authentication policies for each user, or class of users, whom may access the enterprise network. For example, one particular user may need permission to access the enterprise network from any access point, whereas another user for security reasons is to be restricted to use of the hardwired desktop. Although it may possible to restrict access based on the type of access point, such that a user name and password is authenticated only if the access point attributes in the request also match the access point attributes authorized for the user in the authentication server, it would appear that reliance upon such attribute matching would unduly burden the enterprise administrator and otherwise not provide any flexibility by allowing the enterprise administrator to author different authentication policies for each type of access. Accordingly, there exists a need to provide an ability to author and apply different policies to different types of network access.